A debugging tool or debugger is a software program that helps a developer to analyze the malfunctions (bugs) of a program. Generally, the program to be debugged is run via the debugger and runs normally. The debugger then offers the programmer the facility to control the running of the program by allowing him by various means to stop a program-running step and observe, for example, the content of the different variables in the memory. The running step may then be observed, for example, in order to determine the cause of a fault.
Currently, for the dynamic debugging of a module loaded by the kernel of an operating system, it is necessary to perform the following operations manually during the running. The operating system kernel is booted and the debugging tool is connect. The module to be debugged is loaded. Each module will then be loaded at a dynamic memory address by the operating system. This memory address is not known in advance and can vary. (This is the reason why the term “dynamic debugging” is used.) The operating system kernel is interacted with in order to obtain the list of the sections/memory addresses of the module. The symbols associated with these sections are supplied to the debugging tool.
Once these steps have been carried out, the debugging of the module with all its symbols (binary code and data) can be carried out.
One problem is that the file relating to the module present on the hard disk does not contain any dynamic information such as the loading addresses of the different sections of the module allocated by the operating system.
This then means that this information necessary for the debugging must be obtained manually during the running, which requires specific knowledge of the operating system kernel, which may be complex, and which entails communication exchanges between the debugging tool and the memory of the operating system, which may be time-consuming.
Furthermore, the returned memory address is generally that of the main section of the module. Thus, if one or more variables are located in other sections of the module, they cannot be observed during the debugging.
Furthermore, when a module is loaded, the debugging of the module is currently based on the principle that the loading of the module has been successful. However, in the opposite case, an initialization function (Init) may reveal a malfunction (bug). Furthermore, no information on this “Init” function is available during the loading.